Revision: kernel-package--devel--0.2--patch-28
Archive: srivasta@debian.org--2003-primary
Creator: Manoj Srivastava <srivasta@debian.org>
Date: Wed Feb 18 18:08:43 CST 2004
Standard-date: 2004-02-19 00:08:43 GMT
Modified-files: kernel/README.modules kernel/rules
New-patches: srivasta@debian.org--2003-primary/kernel-package--devel--0.2--patch-28
Summary: Pass in EXTRAV_ARG to the subordinate third party module builds
Keywords: 


	 Starting with kernel version 2.6.X, the build process is
 for third party modules has been modified; now modules are expected
 to build in hte kenrel sources dir, and you set the SUBDIR arg to
 point to the source for the module itself. This arranges for the
 kernel makefiles to do all the boilerplate work of building/running
 modpost, dependencies, et cetera.  Here's the "new" way of building a
 kernel module (both as used by alsa-source and as recommended by the
 kbuild maintainer):
                                                                                
 ifdef NEW_KBUILD                                                               
         $(MAKE) -C $(CONFIG_SND_KERNELDIR) SUBDIRS=$(MAINSRCDIR)/kbuild modules
 else                                

	The problem is that unless the module passes in the same
 EXTRAVERSION=XYZ argument that the main kernel build process did,
 include/linux/version.h shall be regenerated, with a different value
 now than when the kernel was compiled. The only way to avoid this is
 to make sure the module passes EXTRAVERSION also; the 2.6 kernel
 makefile is very enthusiastic about making sure version.h is up to
 date.

	So, make-kpkg now passes a new parameter, KPKG_EXTRAV_ARG, to
 the module; the value is either empty, or a string like
  "EXTRAVERSION=X.Y.Z". The idea is that you can call 
     $(MAKE) $(KPKG_EXTRAV_ARG) ... 
 and have the same version.h info as the main kernel image does.
